.NET Remotingでサーバとクライアントのリモートクラス定義が食い違った場合どうなるか?

　世間ではWebサービスだのSOAPだのというキーワードが喧伝されていますが。それらは、単なるプロセス間のメソッド呼び出しに使うには、あまりに重すぎます。しかも、Visual Studio .NETの世界で考えると、IIS経由出なければ呼び出せません。つまり、Windowsサービスのプロセスには、Webサービスのインターフェースを付けられません。

　それを考えると、むしろ.NET Remotingの方が使えると言えます。これはWindowsサービスのプロセスにも付けられるし、しかも高速なバイナリー形式も使えます。

　そこで次の問題は、どこまでサーバ側とクライアント側の不整合が許されるかです。当然、リモーティングを行う場合、サーバ側とクライアント側のプログラムが別々にビルドされて実行されるわけですが、リモート呼び出しされるクラスの定義が食い違っている場合があり得ます。これは、スパイラルに開発して行く過程で機能が増えていく状況を考えれば、よくありそうなことだと言えます。

　とはいえ、軽く調べた範囲では、クラスの定義が食い違ったらどうなるのかということが分かりませんでした。もっと調べれば分かるかも知れませんが、とりあえず、「やってみれば、少しは分かる」ということで、テストプログラムを書いてみました。

　その結果……。

　既存メソッドは無変更でメソッドが増えた場合:　特に問題なく呼び出し可能。

　既存のメソッドの引数を増やした場合: 引数の数が合わないという例外を投げて中断。

　というわけで、わりとサバイバビリティは高いことが分かりました。おそらく、単なるサーバ側のメソッド追加だけなら、問題なく通るでしょう。

　引数を変えたい場合は、既存のメソッドは残したまま、引数が多いメソッドを新規追加すれば良さそうです。

　万一、既存メソッドに単純に引数を追加しても、適切な例外で問題を早期発見できそうです。